Modern software development has its own terminology and, herein at the beginning, a tutorial in definitions as used herein may be helpful. An application is a software program used by an end user; examples of applications include a scheduling client program or application wherein a person may schedule employees' work days; a word processing application; a presentation application to prepare slides for a talk; a database application in which to manipulate data; a spreadsheet application, etc. A tool is a software application that enables a software developer to write additional applications. Examples of tools include: a remote-accessing tool; a database tool to access and manipulate remote relational database tables, columns and rows; a message queue tool to access and manipulate remote message queues; an import tool to select files on a remote system for importing into an ongoing software development project; a performance tool to access and configure remote performance; a tracing tool to trace execution of remote performance, a file tool to access folders and files in the file system of a remote system, etc. A component is software code that can be reused across multiple applications; in other words, a component is standard software that can be pulled off a server and incorporated into new applications using a tool by software developers. For example, a calendar component may be used in several applications such as a scheduling application, a presentation application, a data base application to calculate employee's vacation and pay, etc. Thus, a software developer uses tools to pull components from a local or remote server to create applications.
Software developers found it was first convenient and then necessary to have all code generation tools under one umbrella, called an integrated development environment (IDE). Integrated development environments, as the name suggests, give the software engineer an environment wherein the appropriate tools needed for source code editing, compiling, linking, testing, debugging, and profiling are seamlessly integrated. The advantage of using an integrated development environment is that the software developer need not be concerned about the tool interfaces when moving from one phase of code development to the other. Typically the integrated development environments track the phase of code generation and take appropriate actions of invoking the necessary tool.
Examples of a software development, analysis, and maintenance environments have been known for over twenty years, one of the first was Genera by Symbolics and LISP. For Unix programmers, FUSE is an integrated development environment that has tools that include editors, program builders, source code managers, debuggers, cross-referencers, call graph browsers, file comparison tools, main page hypertext viewers, search tools, performance profilers, heap analyzers, program visualizers, and an optional C++ class browser. Other examples are IBM's VisualAge products, VisualAge C++ and VisualAge for Java. VisualAge C++ provides an environment and toolset for multiplatform object oriented application development with class libraries and frameworks to build applications on AIX. VisualAge for Java is IBM's Java development environment to build Web-enabled enterprise applications with support for building and testing Java applets, servlets, and Enterprise JavaBeans. There are many other integrated development environments, but basically it can be seen that integrated development environments may provide a complete capability for building, editing, compiling, dynamically and statically analyzing programs, configuring, source browsing, and debugging, etc.
Because there was a serious need in the industry for an open source integrated development environment that supported C and C++ in addition to Java, IBM and RedHat developed an integrated development environment called Eclipse to develop software in a myriad of computer languages. Eclipse runs not only on Linux but also other operating systems. There is some special interest in Linux because it is an open source operating system, meaning that it does not belong to a single one company, but is owned and developed by the public. The Eclipse integrated development environment is thus an open source environment for creating, integrating and deploying application development tools across a broad range of computing technology. Eclipse provides a common set of services and establishes the framework, infrastructure, and interactive workbench to build application software and related elements. Eclipse includes, inter alia, a source code editor with code browsing and navigation features like code assist, syntax based color highlighting and integrated help facilities that uses a graphical user interface.
Eclipse.org is an open consortium of software development tool vendors that collaborate to create development environments and product integration and share an interest in creating easy-to-use and interoperable products based upon plug-in technology. By collaborating and sharing core integration technology, tool vendors can concentrate on their areas of expertise and the creation of new development technology. Eclipse.org now includes members and founding steward companies: Borland, IBM, MERANT, QNX Software Systems, Rational Software, RedHat, SuSE, TogetherSoft and WebGain.
Although the Eclipse platform has built-in functionality, most of that functionality is very generic. Additional tools are necessary to extend the platform to work with new content types, to do new things with existing content types, and to focus the generic functionality on something specific. Eclipse is built on a mechanism for discovering, integrating, and running modules called plug-ins. The plug-in mechanism is used to partition Eclipse itself. Indeed, separate plug-ins provide the workspace, the workbench, and so on. When Eclipse is launched, the software developer is presented with an integrated development environment composed of the set of available plug-ins. Even the Eclipse platform runtime itself has its own plug-in. A tool provider writes a tool as a separate plug-in that operates on files in the workspace and surfaces its tool-specific user interface in the workbench.
Eclipse Tutorial
Following is a brief tutorial on Eclipse with many concepts carrying over to integrated development environments in general. If the reader is familiar with Eclipse or integrated development environments, then she/he may wish to skip this section. With respect to FIG. 1, Eclipse has several compartments.
Plug-Ins
The smallest unit of the Eclipse platform that can be developed and delivered separately is the plug-in. Usually a small tool is written as a single plug-in, whereas a complex tool has its functionality split across several plug-ins. Except for a small kernel known as the Platform Runtime, all of the Eclipse Platform's functionality is located in plug-ins. A typical plug-in consists of Java code in a Java Archive (JAR) library, some read-only files, and other resources such as images, web templates, message catalogs, native code libraries, etc. Some plug-ins do not contain code at all, an example of which is a plug-in that contributes online help in the form of HTML pages. A single plug-in's code libraries and read-only content are located together in a directory in the file system, or at a base URL on a server. There is also a mechanism that permits a plug-in to be synthesized from several separate fragments, each in their own directory or URL. This is the mechanism used to deliver separate language packs for an internationalized plugin. Each plug-in has a manifest file containing XML and declaring its interconnections to other plug-ins. The interconnection model is simple: a plug-in declares any number of name extension-points, and any number of extensions to one or more extension points in other plug-ins.
Because any plug-in is free to define new extension points and to provide new application program interfaces (APIs) for other plug-ins to use, a plug-in's extension points can be extended by other plug-ins. An extension point may declare additional specialized XML element types for use in the extensions. On start up, the Platform Runtime discovers the set of available plug-ins, reads their XML manifest files, and builds an in-memory plug-in registry. Eclipse matches extension declarations by name with their corresponding extension point declarations. Any problems, such as extensions to missing extension points are detected and logged. The resulting plug-in registry is available via the Platform application program interface. Plug-ins cannot be added after startup. Thus, manifest information is available from the plug-in registry without activating the contributing plug-in or loading any of its code. This property is key to supporting a large base of installed plug-ins only some of which are needed in any given user session. Until a plug-in's code is loaded, it has a negligible memory footprint and impact on start up time.
A plug-in is activated when its code actually needs to be run. Once activated, a plug-in uses the plug-in registry to discover and access the extensions contributed to its extension points, without activating any of the contributing plug-ins. The contributing plug-in will be activated when the user selects a preference from a list. Once activated, a plug-in remains active until the Platform shuts down.
The Platform Runtime declares a special extension point for applications. When an instance of the Platform is launched, the name of an application is specified and the only plug-in that gets activated initially is the one that declares that application. By determining the set of available plug-ins up front, and by supporting a significant exchange of information between plug-ins without having to activate any of them, the Platform provides each plug-in with a rich source of pertinent information about the context in which it is operating.
The Eclipse Platform is run by a single invocation of a standard Java virtual machine. Each plug-in is assigned its own Java class loader that is solely responsible for loading its classes. Each plug-in explicitly declares its dependence on other plug-ins from which it expects to directly access classes. A plug-in controls the visibility of the public classes and interfaces in its libraries. This information is declared in the plug-in manifest file; the visibility rules are enforced at runtime by the plug-in class loaders.
The Eclipse Platform Runtime also provides a mechanism for extending objects dynamically. A class that implements an “adaptable” interface declares its instances open to third party behavior extensions. Multiple parties can independently extend the same adaptable objects, each for a different purpose. Any plug-in can exploit this mechanism to add behavior to existing adaptable objects, and to define new types of adaptable objects for other plug-ins to use and possibly extend.
The various tools plugged in to the Eclipse Platform operate on regular files in the user's workspace. The workspace consists of one or more top-level projects, where each project maps to a corresponding user-specific directory in the files system.
A project nature mechanism allows a tool to tag a project in order to give it a particular personality, or nature. For example, the web site nature tags a project that contains the static content for a web site, and the Java nature tags a project that contains the source code for a Java program. A single project may have many different natures so that tools are able to share a project without having to know about each other.
Each project contains files that are created and manipulated by the user. All files in the workspace are directly accessible to the standard programs and tools of the underlying operating system. Tools integrated with the Platform are provided with an application program interface for dealing with workspace resources (the collective term for projects, files, and folders).
The workspace provides a marker mechanism for annotating resources. Markers are used to record diverse annotations such as compiler error messages, to-do list items, bookmarks, search hits, and debugger breakpoints. The marker mechanism is open. Plug-ins can declare new marker subtypes and control whether they should be saved between runs.
The Platform allows several different incremental project builders to be registered on the same project and provides ways to trigger project and workspace-wide builds. An optional workspace auto-build feature automatically triggers the necessary builds after each resource modification operation (or batch of operations). The workspace save-restore process is open to participation from plug-ins wishing to remain coordinated with the workspace across sessions. A two-phase save process ensures that the important state of the various plug-ins are written to disk as an atomic operation. In a subsequent session, when an individual plug-in gets reactivated and rejoins the save-restore process, it is passed a workspace-wide resource delta describing the net resource differences since the last save in which it participated. This allows a plug-in to carry forward its saved state while making the necessary adjustments to accommodate resource changes made while it was deactivated.
The Eclipse Platform user interface is built around a workbench that provides the overall structure and presents an extensible user interface to the user. The workbench application program interface and implementation are built from two toolkits: the Standard Widget Toolkit (SWT) which is a widget set and graphics library integrated with the native window system but is independent of the operating system (OS); and JFace which is a user interface toolkit that simplifies common user interface programming tasks. The entire Eclipse Platform user interface and the tools that plug into it use SWT for presenting information to the user. At this time, it is useful to distinguish between an application program interface (API) and a user interface (UI). APIs are functions that are called by code, not by humans. In Java, these are methods; in COBOL, these are paragraphs; in C and C++ these are functions; and in other languages, these are procedures. A user interface, on the other hand, is an interface with which a human interacts with an application.
The Standard Widget Toolkit—SWT
For each different native window system, the SWT implementation uses widgets that are native to the operating system and the application wherever possible; where no native widget is available, the SWT implementation provides a suitable emulation. Emulated widgets invariably lag behind the look and feel of the native widgets, and the user interaction with emulated widgets is usually different enough to be noticeable, making it difficult to build applications that compete head-on with shrink-wrapped applications developed specifically for a particular native window system. SWT addresses this issue by defining a common application program interface available across a number of supported window systems.
JFace
JFace is a user interface toolkit with classes for common user interface programming tasks. JFace is window-system-independent in both its API and implementation, and is designed to work with SWT without hiding it. JFace includes the usual user interface toolkit components of image and font registries, dialog, preference, and wizard frameworks, and progress reporting for long running operations. Two of its more interesting features are actions and viewers. Actions allow user commands to be defined independently from their exact whereabouts in the user interface to allow the same action to be used in several places in the user interface; thus it is easy to change the location of an action in the user interface without having to change the code for the action itself. Viewers are model-based adapters for certain SWT widgets. Viewers handle common behavior and provide higher-level semantics than available from the SWT widgets. The standard viewers for lists, trees, and tables support populating the viewer with elements from the client's domain and keeping the widgets in synch with changes to that domain. The standard viewer for text supports common operations such as double click behavior, undo, coloring, and navigating by character index or line number. Text viewers provide a document model to the client and manage the conversion of the document to the information required by the SWT styled text widget. Multiple viewers can be open on the same model or document; all are updated automatically when the model or document changes in any of them.
The Workbench
Unlike SWT and JFace, which are both general purpose user interface toolkits, the workbench provides the user interface personality of Eclipse and supplies the structures in which tools interact with the user. Because of this central and defining role, the workbench is synonymous with the Eclipse user interface as a whole and with the main window the user sees when Eclipse is running.
The Eclipse user interface paradigm is based on editors, views, and perspectives. From the user's standpoint, a workbench window consists visually of views and editors. Views provide information about some object that the user is working with in the workbench. A view may augment other views by providing information about the currently selected object. For example, the standard properties view presents the properties of the object selected in another view. Views have a simpler life cycle than editors: modifications made in a view, such as changing a property value, are generally saved immediately, and the changes are reflected immediately in other related parts of the user interface. Editors allow the user to open, edit, and save objects, and follow an open-save-close life cycle much like file system based tools but are more tightly integrated into the workbench. When active, editors can contribute actions to the workbench menus and tool bar. The Platform provides a standard editor for text resources; more specific editors are supplied by other plug-ins. Perspectives manifest themselves in the selection and arrangements of editors and views visible on the screen. A workbench window can have several separate perspectives only one of which is visible at any given moment. Each perspective has its own views and editors that are arranged, e.g., tiled, stacked, or detached, for presentation on the screen. Several different types of views and editors can be open at the same time within a perspective. A perspective controls initial view visibility, layout, and action visibility. The user can quickly switch perspective to work on a different task, and can easily rearrange and customize a perspective to better suit a particular task. The Platform provides standard perspectives for general resource navigation, online help, and team support tasks.
Tools integrate into this editors-views-perspectives user interface paradigm in well-defined ways. The main extension points allow tools to augment the workbench by adding new editors, views, perspectives, while arranging old and new views to suit new user tasks. Tools may also augment existing editors, views, and perspectives by adding new actions to an existing view's local menu and tool bar, to the workbench menu and tool bar when an existing editor becomes active, to the pop-up content menu of an existing view or editor, and by adding views, action sets, and shortcuts to an existing perspective.
Eclipse thus takes care of all aspects of workbench window and perspective management. Editors and views are automatically instantiated as needed, and disposed of when no longer needed. The display labels and icons for actions contributed by a tool are listed in the plug-in manifest so that the workbench can create menus and tool bars without activating the contributing plug-ins.
Tools written in Java using Eclipse's APIs achieve the highest level of integration with the Platform. At the other extreme, external tools launched from within the Platform must open their own separate windows in order to communicate with the user and must access user data via the underlying file system. Their integration is therefore very loose, especially at the user interface level.
Version and Configuration Management (VCM)
The team support component of Eclipse adds version and configuration management (VCM) capabilities to projects in the workspace and augments the workbench with all the necessary views for presenting version and management concerns to the user. Eclipse's team support model has advanced features of (1) multiple heterogeneous repositories; (2) lightweight model of team collaboration; and (3) resource versions. The team support model centers on repositories that store version-managed resources on shared servers. Eclipse is designed to support a range of existing repository types in which a single workspace can simultaneously access different types of repositories.
A stream maintains a team's shared configuration of one or more related projects and their folders and files. A team of developers share a stream that reflects their ongoing work and all their changes integrated to date. In effect, a stream is a shared workspace that resides in a repository.
Each team member works in a separate workspace and makes changes to private copies of the resources. Other team members do not immediately see these changes. At convenient times, a developer can synchronize their workspace with the stream. As a team member produces new work, they share this work with the rest of the team by releasing those changes to the stream. Similarly, when a team member wishes to get the latest work available, they catch up to the changes released to the stream by others. Both synchronization operations can be done selectively on resource subtrees, with an opportunity to preview incoming and outgoing changes. When the repository type supports an optimistic concurrency model, conflicting incoming and outgoing changes are detected automatically. The developer resolves the conflict, usually by merging the incoming changes into their local workspace, and releases the result. This concurrency model supports groups of highly collaborative developers who work on a common base of files and who frequently share their changes with each other. It also supports developers who work offline for long periods, connecting to their repository only occasionally to synchronize with the stream.
A repository typically may have any number of streams, which are distinguished by name. Streams act as lightweight containers for building product releases, and as safe places to store a developer's personal work and early prototype versions outside the team's main development stream. When the same project appears in different streams, the resources evolve independently so that changes released to one stream have no effect on other streams. Heterogeneous repositories and repository types are supported so that each project in the workspace can be managed in a different type of repository. The workspace records stream-specific synchronization information for a project's resources which detect incoming and outgoing file creations, deletions, and content changes.
Help
The Eclipse Help mechanism allows tools to define and contribute documentation to one or more online books. For example, a tool usually contributes help style documentation to a user guide, and API documentation, if any, to a separate programmer guide. Raw content is contributed as HTML files. The facilities for arranging the raw content into online books with suitable navigation structures are expressed separately in XML files. This separation allows pre-existing HTML documentation to be incorporated directly into online books without needing to edit or rewrite them.
In summary, Eclipse provides a nucleus of generic building blocks and application program interfaces like the workspace and the workbench, and various extension points through which new functionality can be integrated. Through these extension points, tools written as separate plug-ins can extend Eclipse. With Eclipse, the user is presented with an integrated development environment that is specialized by the set of available tool plug-ins, but rather than being the end of the story, Eclipse is really just the beginning. Tools may also define new extension points and APIs of their own and thereby serve as building blocks and integration points for yet other tools.
End of Eclipse Tutorial
The quality of the experience when using an integrated development environment depends significantly on how well the tools integrate with the integrated development environment and how well the various tools work with each other. This integration and coordination becomes increasingly important in an open source system such as Linux and Eclipse. A connection captures the information needed for a tool to access a remote system. Depending on how the tool communicates with the remote system, this information could include the transmission control protocol/internet protocol (tcp/ip) hostname of the remote system, and the port number that the tool uses to talk to its code or daemon or service running on that remote system. Most remote-accessing tools permit the user to define this information once and then save it in a local file so that it can be reused. All such integrated development environment remote-accessing tools or plugins require the end-user to pre-define a connection to a remote system, and the tools do not recognize each other's connections. If every remote-accessing tool has its own unique support for defining connections, then a user may have to pre-define multiple connections to the same remote system, one for each tool the user uses. Each remote-accessing tool offers its own unique user interface and hence its own unique experience for the end-user. Until a user becomes experienced in each tool, this increases their frustration and reduces their productivity. These two shortcomings of the prior art are illustrated in FIG. 2.
In FIG. 2, there are three remote systems 20, 22, 24. Each system is a computer that contains different types of resources of interest and connected through a network 30 to an integrated development environment user. At the bottom of FIG. 2, an integrated development environment 40 for a particular software developer has three remote-accessing tools 42, 44, 46, most likely authored by different tool writers possibly having no knowledge of each other or each other's tools. In FIG. 2, each remote system 20, 22, 24 has two tools with predefined connections to it, e.g., remote system 20 has predefined connections to Tool A 42 and Tool B 44, and remote system 22 has predefined connections to Tool B 44 and Tool C 46 and so on for a total of six connections. The limited and predefinition of these connections presents a first problem hinted at in the Eclipse tutorial. It would make more sense to have only three predefined connections because there are only three remote systems. A second problem illustrated by the scenario of FIG. 2 is that because each remote-accessing tool was independently authored, each may offer a completely unique experience for the integrated development environment user.
There is thus a need in the software development industry for sharing connections to tools among remote systems and for a common user interface for remote systems.